Introduction to the Infinity Web Service APIs
We’ve engineered all Infinity-based applications so that they expose their data (and metadata!) via web services. Every data form, record operation, data list, batch, query, search list, etc., can be completely accessed (and manipulated!) using one of the various endpoints described by the web service. At last count, there are over 16,000 distinct features in the system, which means there are over 16,000 distinct web service endpoints you can call! When you consider that you can even use the Infinity Platform SDK to add brand new features to the system (which in turn automatically yield brand new web service endpoints for those features), the breadth of functionality exposed to consumers is staggering! Technically, there are only ~200 physical endpoints that make up the Infinity web service (AppFxWebService.asmx). All features in the system are accessed using those endpoints, so the number of logical endpoints grows as the number of features in the system grows.
Does your code have direct access to the database server?
If you are faced with the task of writing custom code that interacts with an Infinity-based application, you must initially ask yourself this question: Will my code live on the local network and have direct access to the database server? If so, you can use the System.Data.SqlClient namespace that is the .NET Framework Data Provider for SQL Server to talk directly to the Infinity SQL Server database. If your code does not have direct access to the Infinity database, then you need other options to talk to the Infinity application.
Non .NET programmers can use the AppFxWebService.asmx (SOAP/XML). Dot NET programmers can use assemblies which wrap the AppFxWebService.asmx or simply use AppFxWebService.asmx directly
This article explores different ways to use the major Infinity Web Services APIs to talk to an Infinity Web Server from a custom client application over HTTP. By client application, we mean both custom web applications and forms-based applications that talk over the wire through HTTP to an Infinity Web Server that houses an Infinity-based application such as Blackbaud CRM. This article describes the various HTTP- based API options and the pros and cons of the options, and it provides some examples along the way. The Infinityplatform is designed specifically to allow integration scenarios, and as part of that design, every application feature is accessible through standard web services accessible from any programming tool that utilizes XML, HTTP, and SOAP. Fortunately, Blackbaud provides different HTTP-based API options that you can use to get the job done. To view these endpoints, click the Endpoints link on the splash page of Blackbaud CRM:
As you probably know by now, Infinity is an application platform on which Blackbaud products such as Blackbaud CRM, Blackbaud Direct Marketing, and ResearchPoint are built. An Infinity application is a sum of its individual features. Blackbaud products built on the Infinity platform are an aggregation of features such as a data list to display data, an Add Data Form to add data, a delete record operation to delete data, a search list to locate a record, etc. Both existing features created by Blackbaud and custom features created by third-party developers are developed with the Infinity SDK. Using the Infinity SDK, a developer can create new features by authoring XML specs and then loading these features into the Infinity catalog. After features are loaded, they automatically are available from at least one Web API. Any code that you write which lives outside the Infinity Web Server can not access an Infinity database directly. Instead, a developer can rely on a Blackbaud HTTP-based API/Web Service to access an Infinity feature. Access to web services may be accessed by directly referencing the endpoint ASMX and building the WSDL file or (if you are a .NET programmer) you can reference a client side DLL that wraps an endpoint.
The four API choices can be broken down into two broad categories:
Loosely Typed with Access to All Features
Strongly Typed with Access to a Limited Set of Features
The grid below summarizes and compares each web API option.
And now a word about security…
Each feature type (data lists, data forms, record operations, etc.) can be secured through configuration within the application. Application-defined security on a feature is respected by all of the APIs listed above. If someone does not have rights to access a feature, then they can not access it through the APIs listed above. Each feature type has a feature page where you can manage security for the feature. A typical step in real world use of the API is to first secure the feature. By navigating to a feature page, you can simply add the feature to a security role.
For more information on securing Infinity features, see Add Features to Infinity System Role and Authentication and Authorization.